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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 14 of a multi-part deliverable. Full details of the entire series can be found in part 1 [1]. 



Introduction 

CPCM is a system for Content Protection & Copy Management of commercial digital content dehvered to consumer 
products. CPCM manages content usage from acquisition into the CPCM system until final Consumption, or Export 
from the CPCM system, in accordance with the particular usage rules of that content. Possible sources for commercial 
digital content include broadcast (e.g., cable, satellite, and terrestrial), Internet-based services, packaged media, and 
mobile services, among others. CPCM is intended for use in protecting all types of content - audio, video and associated 
applications and data. CPCM specifications facilitate interoperability of such content after acquisition into CPCM by 
networked consumer devices for both home networking and remote access. 

This first phase of the specification addresses CPCM for digital Content encoded and transported by linear transport 
systems in accordance with TS 101 154 [i.l]. A later second phase will address CPCM for Content encoded and 
transported by systems that are based upon Internet Protocols in accordance with TS 102 005 [i.2]. 
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Scope 



The present document is the specification of the Digital Video Broadcasting (DVB) Content Protection and Copy 
Management (CPCM) Extensions. It contains the normative specifications of each standardized Extension to CPCM. 



References 



References are either specific (identified by date of pubhcation and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 825-1: "Digital Video Broadcasting (DVB); Content Protection and Copy 

Management (DVB-CPCM); Part 1: CPCM Abbreviations, Definitions and Terms". 

[2] ETSI TS 102 825-4: "Digital Video Broadcasting (DVB); Content Protection and Copy 

Management (DVB-CPCM); Part 4: CPCM System Specification". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 101 154: "Digital Video Broadcasting (DVB); Specification for the use of Video and 

Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream". 

[i.2] ETSI TS 102 005: "Digital Video Broadcasting (DVB); Specification for the use of Video and 

Audio Coding in DVB services delivered directly over IP protocols". 

[i.3] ETSI TR 102 825-12: " Digital Video Broadcasting (DVB); Content Protection and Copy 

Management (DVB-CPCM); Part 12: CPCM Implementation GuideUnes 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 825-1 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 825-1 [1] apply. 
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Introduction 



The CPCM System provides an interoperability platform and common trusted destination for commercial content in the 
consumer environment. CPCM is a flexible system that can be extended both in a standard way and in a proprietary 
way. 

The present document describes CPCM Extensions standardised by DVB together with corresponding extension 
elements or protocols. 

Currently, the following standardised CPCM Extensions are defined: 

• Play Count extension 

Other CPCM Extensions may be defined in a next release of the present document. 

EXAMPLE: This may happen when an extension is developed after the completion of the Rule Set of a specific 
C&R Regime. 



5 Interoperability 

A CPCM Extension implementation is optional. 

A CPCM Instance receiving a CPCM message as described in TS 102 825-4 [2] shall ignore any element relative to an 
extension it does not contain and shall thus behave as if the extension element was not present. It shall ignore any 
message dedicated to an extension, such as cpcMextensionmessage or CPCMprivatedatamessage, but may reply 
with the appropriate error message as defined in TS 102 825-4 [2]. However, it shall not remove any element relative to 
an Extension from the Auxiliary Data. 

Table 1 gives the CPCM Extension Identifiers for CPCM Extensions defined in this specification. Other identifiers are 
reserved. 

Table 1 : CPCM Extension Identifiers 



CPCM Extension Name 


CPCM Extension Identifier 


Play Count 


0x0001 



6 Play Count Extension 

6.1 Play Count Extension definition 

The purpose of this extension is to limit the number of consecutive plays of a given content item. 

If USI SVCA is not asserted, any number of simultaneous plays is allowed. If SVCA is asserted, the number of granted 
permissions in SVCA determines the maximum number of simultaneous viewings that constitutes one play. This also 
applies to stored CPCM content. 

EXAMPLE: If SVCA is 2,5 concurrent viewings will be considered as 3 plays. 

The definition of what constitutes one play is out of the scope of the present document and left to CPCM C&R Regimes 
to determine. 
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6.2 Play Count Data element 



Play count extension makes use of one extension data element cpcm play count data element. This, data element is 

composed of two fields: CPCM_play_limit and CPCM_play_remaining. 

CPCM play limit is an 8-bit integer that, when inserted in a CPCM Auxiliary Data relative to a CPCM Content 
Licence, gives the original play count for the associated Content Item. 

CPCMpiay remaining is an 8-bit integer that, when inserted in a CPCM Auxiliary Data relative to a CPCM Content 
Licence, gives the remaining play count for the associated Content Item. Alternatively, when used in the Move protocol, 
CPCM play remaining expresses the number of plays that are being moved to the other device, as described in 
clause 6.4.5. 

EXAMPLE: The system is able to inform the user that they still have 3 plays remaining out of the original 5 
using the two extensions data elements. 

Play count data extension does not use any other extension data element. 

The format of CPCM_play_count_data_element is shown in Table 2. 

Table 2: CPCM Content Licence Identifier 



Syntax 


Bits 


Identifier 


CPCM_play_count_data_element () { 

CPCM_play_limit 

CPCM play remaining 
} 


8 
8 


uimsbf 
uimsbf 



Semantics for CPCM_content_licence_identifier: 

CPCM_play_limit: This field indicates the original play count for the associated content item. 

CPCM_play_remaining: This field indicates the remaining or the requested play count for the associated content item. 

6.3 Play Count protocols 

There are no protocols specific to the play count Extension. 

Play count extension affects the Move protocol. This protocol can be used to move content with a partial amount of the 
outstanding authorised plays to another Storage Entity. 

To that end, play count data element shall be inserted in the optional part, as described in TS 102 825-4 [2] of the 
following messages: 

• CPCM Content Licence Move Invite: In this message , cpcMpiayremaining field in the 
cpcM_piay_count_data_eiement which is inserted in the message extension indicates the number of plays that 
are invited to be moved. If this number is greater than the outstanding counts, all the counts will be moved. 

• CPCM Content Licence Move Begin: In this message cpcMpiayremaining field in the 
cpcM_piay_count data element which is inserted in the message extension indicates the number of plays that 
are proposed to be moved. 

• CPCM Content Licence Move Request: In this message cpcMpiayremaining field in the 

CPCM play count data element which is inserted in the message extension indicates the number of plays that 
are eventually requested. 

If all the outstanding play counts are to be moved, there is no need to use the Play Count Extension element in the 
above messages since the relevant information is already included in the content licence that is to be moved. 

Play Count extension shall be added also in the following message: 

• CPCM Instance Enquiry Response message: If the Instance implements the Play Count extension, it shall 
insert in the conditional part of the message CPCM Extension element with no data. 
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• CPCM Discovery Response message: If the Instance implements the Play Count extension, it shall insert in the 
conditional part of the message CPCM Extension element with no data. 

Play Count Extension Element shall be ignored when inserted in any other messages. 

6.4 Content Management 
6.4.1 USI setting 

The Play Count extension may be used in conjunction with any USI settings. However, when used with the following 
USI, the Play Count extension can no more be enforced: 

• If Copy Control Information is set to Copy Control Not Asserted, any number of copies may be made by any 
CPCM Instance, including a CPCM Instance that does not implement the Extension. Consequently, the 
number of authorised plays can no longer be effectively controlled. 

• If Copy Control Information is set to Copy Never, the content cannot be stored. Thus, the play count is 
equivalent to SVCA control and not useful. 



• 



If Viewable is asserted, any Consumption Point, including an Instance that does not implement the Extension, 
shall be able to play the content, if authorised by the USI. Thus, the count control cannot be accurate. 



The assumption in this specification is that Play Count restricted content is always used with Viewable not asserted and 
with CCI set to "Copy Once" at the Acquisition Point or "Copy No More" after the first recording. 

6.4.2 Device and Content Discovery 

The presence of Play Count Extension in Auxiliary Data shall be signalled with other present Auxiliary Data. 

In addition to advertising the content as "Not Viewable" with "Copy Once" or with "Copy No More", as described in 
clause 6.4.1, and play count extension. Storage Entities and Acquisition Points shall also advertise the content as 
"Viewable" with "Copy No More" to enable interoperability with Instances that do not implement the Extension. .A 
CPCM Instance implementing the Play Count Extension shall signal it in CPCM Enquiry Response and CPCM 
Discovery Response messages. 

6.4.3 CPCM Functional Entity Beinaviour 

A CPCM Instance that does not support this extension shall ignore it and enforce the USI as if the Extension was not 
present. 

Only CPCM Acquisition Points and Storage Entities shall adopt a specific behaviour with regard to Play Count 
Extension. This specific behaviour concerns the USI enforcement step, as described in clause 6.4.4. 

6.4.4 USI Enforcement 

6.4.4.1 Controls prior to content transfer 

All the controls related to the USI setting shall be performed with exception to the "Viewable" USI that can be sourced 
to Consumption Points or Export Point under the conditions described below. 

The behaviour described below regards only Acquisition Points or Storage Entities implementing the Extension. All 
other Acquisition Point and Storage Entities shall enforce USI as described in TS 102 825-4 [2]. 

Play Count restricted content, sourced by an Acquisition Point or a Storage Entity, which may be through a Processing 
Entity, shall be sourced as "Viewable" and "Copy No More" content, if the cpcm play remaining is greater than zero. 
In such a case, the Acquisition Point or the Storage Entity shall decrement the value of CPCM_piay_remaining in the 
CPCM Content Licence by one. 

NOTE 1 : A CPCM C&R regime may authorise an Instance to revert to the previous Licence if the criteria that one 
play was actually made are not fulfilled. 
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EXAMPLE: If only a few seconds of the content were played, the status of the associated Content Item may be 
known using CPCM content item status protocol described in TS 102 825-4 [2]. 

An Acquisition Point may source Play Count restricted content to only one Storage Entity as "Copy Once" Content. 

A Storage Entity may send Play Count restricted content to another Storage Entity for the purpose of making a copy 
only through the Move protocol. 

An Acquisition Point that sources content to a Consumption Point or an Export Point, which may be through a 
Processing Entity, shall update correspondingly cpcm play remaining in the extension before sourcing to a Storage 
Entity. It may generate several Content Licences sourced to different Storage Entities as long as the total of 
CPCM play remaining fields in the different Content Licences matches the actual remaining play count. 

If SVCA is also asserted only one Play shall be counted as long as the number of granted permissions is lower or equal 
to the value of simultaneous view count. Upon receipt of a permission request when the number of granted 
permissions is equal to simultaneous view count, the CPCM Instance verifies the status of each CPCM Instance to 
which a permission was granted using the same protocol as described in TS 102 825-4 [2]. If the number of positive 
answers that are received is lower than the granted permissions, it behaves as described in TS 102 825-4 [2]. Else, if the 
number of outstanding play count is zero, it denies the permission. Else, the permission is granted and the number of 
outstanding Play Count is decremented by one. 

The same controls shall be applied each time the number of granted permissions equals a multiple of 
simuitaneousviewcount and play count data element is greater than zero. 

If the C&R regime allows a grace period before decrementing the play count data element, the source CPCM Instance 
shall run the protocol to verify the status of each CPCM Instance to which permission was granted before this grace 
expires. If the number of positive answers is below the relevant multiple of simultaneous view count, the play count 
will not be decremented. 

NOTE 2: Security control implementations need to make sure that it is not possible to restore to the device a 
duplicate Content Licence which was made before a Play occurred. The CPCM Implementation 
Guidelines, TR 102 825-12 [i.3], give examples on how to prevent this. 

6.4.4.2 Controls to be enforced when receiving content 

All the controls related to the other USI setting shall be performed. There is no specific control related to Play Count 
extension. 



6.5 Move Protocol 



Before starting the Move protocol, the Source CPCM Instance checks whether the number of counts to be moved is 
lower than the remaining count. If not, or if this number was not given in the Move invitation, either from the peer 
CPCM Instance of from the user interface, it shall Move the entire count. 

If all the remaining plays are to be moved, the Move protocol runs exactly the same way as described in 
TS 102 825-4 [2]. 

If only a partial number of cpcm play remaining is to be moved, the protocol runs the same way, with the following 
exceptions: 

• CPCMplaycountdataelement with CPCMplayremaining set to the number of COUntS to be moved shall be 
inserted in the messages CPCM Content Licence Move Begin, CPCM Content Licence Move Request and, if 
used, CPCM Content Licence Move Invite. 

• The Security Control of the Source CPCM Instance creates two new Content Licences, one with the remaining 
play count and one with the "to be moved" count. This is performed just after disabling the previous Content 
Licence. 

• Upon receipt of a CL Movement request message. Security Control sends the Content Licence with the "to be 

moved" count through a move_CL_response_message . 

• Once informed that the Content Handling has received a move_CL_conf irmjmessage, the Security Control 
erases the disabled Content Licence. 
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Content can be Moved, with partial or total play count, to a Storage Entity that does not implement the Play Count 
extension. The content will not be viewable from this Storage Entity but will be Movable, with the total count only, to a 
Storage Entity that implements the Extension using standard Move Protocol. 

NOTE: If the Move occurs with a Storage Entity that already holds a Content Licence for the same Content, if 
allowed by the applicable C&R regime, an implementation may generate a new Content Licence with 

aggregated extension CPCMplayremaining. 

6.6 Content Licence Management 

6.6.1 Content Licence Generation 

Content Licence is generated as described in TS 102 825-4 [2]. A new CL shall be generated, with updated Auxiliary 
Data digest, each time a new play or a CL move with partial count occurs. 

6.6.2 Content Licence Verification 

Content Licence shall be verified as described in TS 102 825-4 [2]. 

6.6.3 Content Licence Protection 

The Play Count Extension requires SAC/Device protection mode for the associated Content Licence. 
The protection mode for Content Licence shall be chosen as described in TS 102 825-4 [2]. 
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